This warning is indeed annoying and there still seems to be no way to silence it (without silencing all Interface Builder warnings) in Xcode 11. I have a similiar related warning for not using autolayout constraints "views without layout constraints may clip their content".I have a xib that does not use autolayout at all. This view uses manual layout...I know, I know, you want me to use autolayout but the view works just fine the way it is and I see no reason to start using autolayout just for the sake of using it.I have a label with text that changes. After the text change I make a sizeToFit call. I don't need or want autolayout here. While I understand this warning may be useful in some cases for some xibs, there should be a way to disable it IMO.

Just found it. You can do it now by clicking Editor -> Preview in the menu bar in Xcode 11.

So I guess the way to do this would be to change the code in the previous post to set the isWaitingOnReceiverToAcceptInvite flag to NO in the MCSessionStateConnecting state. I guess if the other device declines the invitation the delegate method will transition to MCSessionStateNotConnected and won't enter the MCSessionStateConnecting state.In the case of an error, usually it seems the state goes from MCSessionStateConnecting -> MCSessionStateNotConnected (though I'm not sure if this is true 100% of the time, or if there could be an immediate error apart from an invitation being declined).Not sure if this is documented somewhere or not but this is my best guess. Still there doesn't really seem to be a way to access any sort of error that occurs during invite/connecting phase to determine whether or not it's appropriate to retry connecting or just give up and present an error.

I may end up having to look into the Network framework if I want to pursue this more which is a shame because I spent a good amount of time digging into the Multipeer Connectivity framework. Thanks a lot for taking the time to reply with that.>Can you tell me a little bit more about this workflow? For example, are you wanting to use peer-to-peer to communicate with another device on a network?I want to be able to send data to nearby devices. MultipeerConnectivity seemed like a good fit because it's high-level and easy and I don't really care if the nearby device is on wifi, bluetooth, or ethernet, I only care that the device is nearby. The problem is MultipeerConnectivity might just be a little too high level.As it relates to my concern in my original post (detecting a declined invite) I did in fact run into a situation (only once out of like 99 tests, but enough to make me uncomfortable enough to maybe ditch MPC) where an attempted session transitioned directly to the NotConnecting state even though the testing device on the other end doesn't ever decline invitations. So it does seem like it's possible to enter the NotConnecting stage immediately due to an error while skipping the 'Connecting' stage. So in a real app, if a Peer declines an invite I'd want to alert the user "DeviceName doesn't want to talk to you right now. Goodbye." But if the invite is not declined and there is an error, and the MCNearbyServiceBrowser still has that peer, I can retry the operation. But I don't want to show an alert saying that an invitation was declined to the user when really the connection just dropped.Just a little bit more context as to why the peer's state transitioned to not connecting and multipeerconnectivity framework might be fine for my needs.

>As to your original question; yes, detecting declined invites or dropped invites is something that is not well supported in these APIs. This was part of my reasoning for suggesting Network Framework. A lot of this, as you are finding, ends up having to be handled with manual logic that defines a set of behavior for when it makes sense for you app to consider the invitation declined or that it needs to move on.Yes seemd to be the case. Thanks again for the reply and confirming. Noticed when the other peer in the session transitions to NotConnecting without ever transitioning to connecting *and* the peer doesn't decline the invite (which causes my logic that checks for a declined invitation to fail) this seems to always log out in my console:[MCNearbyServiceBrowser] Received an invitation response from [thedevicename,33485893], but we never sent it an invitation. Aborting!Log is definitely bogus (invitation was sent) so there might be a bug in MCNearbyServiceBrowser. I'm not sure if I could potentially "resolve" my declined invitatiion detection "problem" by using the custom discovery API. @interface MCSession (MCSessionCustomDiscovery) // Gets the connection data for a remote peer. - (void)nearbyConnectionDataForPeer:(MCPeerID *)peerID withCompletionHandler:(void (^)(NSData * __nullable connectionData, NSError * __nullable error))completionHandler; // Connect a peer to the session once connection data is received. - (void)connectPeer:(MCPeerID *)peerID withNearbyConnectionData:(NSData *)data; // Cancel connection attempt with a peer. - (void)cancelConnectPeer:(MCPeerID *)peerID; @end

Not sure how viewing crashes in Xcode is supposed to work either. Wasn't able to find anything useful when clicking "Open in Project."For me, a couple of times I noticed vital information was missing when viewing the crash in Xcode (missing method calls on the stack but they were in the .crash log). So I right-clicked on the crash in the list on the left and choose "Show in Finder" which reveals a package with .xccrashpoint in Finder. I then right clicked that .xccrashpoint package in Finder and choose "Show Package Contents" and then dug through subfolders until I got to the "Log" folder with the .crash files in it. Then I just opened the .crash in Console. Reading the .crash in Console was a lot more useful. Was able to determine what caused the app to crash and was able to fix it in an update.

Yea, the delegate method on NSFileManager really won't work for canceling unless you are copying a directory. Only thing I can think of at the NSFIleManager API level is to try to remove the file while it's still being copied to get the -copyItemAtURL:toURL:error: method to fail with an error.

Okay cool. Thanks for responding. Filed FB7656661Edit: Looks like this is actually documented in the man page (though still seems like a weird design to me) so I expect to get a "behaves as intended" response."Note that if the source path ends in a / its contents are copied rather than the directory itself (like cp(1)). The behavior of a recursive copy on a directory hierarchy also depends on the contents of the destination. If the destination is a directory, the source directory (or its contents, if the source path ends in a / ) will be copied into it. If the destina- tion exists but is not a directory, and the source is a non-empty direc- tory, the copy will fail; the exact error set depends on the flags pro- vided to copyfile() initially."😕

Yeah.....well...copying the folder was still going on after like a half hour in the sandboxed version of the app. Finally gave up. Just tested again..the non-sandboxed version of the app copied the entire directory to the external drive in like 60 seconds. Basically this is the difference between acceptable and unacceptable performance as far as my customers are concerned. Not sure if there's really anything I can do about it though 😟 sadly

Yea was looking for that earlier. Didn't find anything that helped me figure out a workaround sadly.Sandbox: mdworker(22047) deny(1) mach-lookup com.apple.FileCoordinationSandbox: mdworker(22047) deny(1) mach-lookup com.apple.security.syspolicySandbox: bluetoothd(149) deny(1) mach-lookup com.apple.server.bluetootherror 16:37:32.780627-0400 kernel Sandbox: diskarbitrationd(121) System Policy: deny(1) file-read-data /dev/rdisk1s3Sandbox: bluetoothd(149) deny(1) mach-lookup com.apple.server.bluetoothSandbox: mds(119) deny(1) network-outbound /private/var/run/mDNSResponderI do see a good amount of these log out:AFP_VFS afpfs_DoReconnect: Restoring session /Volumes/TheVolumeNameHere..

+1 for this. In AppKIt NSMenuItem can take an attributedString. Would be nice to have equivalent API here.

Interesting. In the Apple example they do this:- (void)completeOperation { [self willChangeValueForKey:@"isFinished"]; [self willChangeValueForKey:@"isExecuting"]; executing = NO; finished = YES; [self didChangeValueForKey:@"isExecuting"]; [self didChangeValueForKey:@"isFinished"]; }In an asynchronous you would usually be off the initial NSOperationQueue that is KVOing isExecuting and isFinished when you generate those KVO notifications (otherwise it wouldn't make much sense to return YES from isAsynchronous).-(void)start { [self generateExecutingStarted]; [self doNetworkWorkWithCompletion:^{ [self completeOperation]; }]; }Not sure what the key value observing code looks like in NSOperationQueue. I'd use atomic_bool, but every Apple sample I find for an isAsynchronous NSOperation doesn't which looks wrong to me.

Yup noticed this too. When a sandboxed app touches .webarchive (moving it) it gets quarantined the user can no longer open the .webarchive. The user gets locked out and can't open his own file unless he knows where to look in System preferences.

+1. I'm looking for a solution too.

Maybe that's their position but seems pretty ridiculous to me if it is. Many apps have been writing .webarchives for years. It's not a problem with writing the file, it's just that the app is sandboxed.This is definitely a bug; the problem isn't with the .webarchive file it's that macOS will refuse to *open* any .webarchive a sandboxed app touches. So even if you save a .webarchive with Safari...and you take that file and move it with a sandboxed app that supports drag and drop, macOS won't open that webarchive anymore even though the user created it with Safari. It will tell you whatever sandboxed app touched it last created the file and the system can't verify that this code signed app from a developer isn't malware, which is bogus.Also as the original poster mentioned, WebView (public api) had support for .webarchive (yes I know it's deprecated) but it's just a plist. My app isn't using WebView to write the webarchive, but that's irrelevant to the bug.If I were to guess there not not preventing sandboxed apps from writing .webarchives because it's some special proprietary format they want to protect. It's either a nasty bug introduced by accident or it's a nasty bug but they did it on purpose to circumvent a deeper security issue they didn't have time to properly fix.Non-sandboxed apps don't have any problems writing or touching web archives.